BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / windows / msk312.zip / KERMIT.BWR < prev next >

Wrap

Text File | 1992-09-29 | 62.0 KB | 1,257 lines

File MSK312.BWR MS-DOS KERMIT 3.12 "BEWARE FILE" September 1992 BUGS, LIMITATIONS, AND HINTS This file applies to both versions 3.11 and 3.12 of MS-DOS Kermit for the IBM PC and PS/2 families and compatibles. If you have problems with MS-DOS Kermit, please read this to find out the status of the problem. It might be known already, and a workaround listed here. Problems in 3.11 that are fixed in 3.12 are noted. The user manual for MS-DOS Kermit 3.11 is the book "Using MS-DOS Kermit", Second Edition, by Christine M. Gianone, published by Digital Press, Bedford, MA (1991), order number EY-H893E-DP. Call 1-800-344-4825 (toll free, USA) to order, or order by mail from Columbia University. Use this file plus the file MSR312.UPD as a supplement to the book. Certain features were added to the dialing directory and the TCP/IP support after press time for the second edition of the book. For greater details about these features, see the MS-DOS Kermit help file, KERMIT.HLP or MSKERM.HLP. For TCP/IP, also see the section at the end of this file. MS-DOS Kermit 3.11 has been successfully tested with PC-DOS 2.0, 3.0, 3.30, 4.0 and 5.0 on a wide variety of IBM PCs, XTs, PC/ATs, PS/2s, and compatibles. DOS 2.0 or later is required for basic operation, and 3.30 or later is required for certain features such as code page switching. Building version 3.12 from source code requires Microsoft MASM and C 6.0 or later. Please report problems via e-mail to Info-Kermit@watsun.cc.columbia.edu or to KERMIT@CUVMA.BITNET, or call (212) 854-5126, or write to Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025, USA. PROBLEMS CORRECTED BY PATCHES IN MSKERMIT.PCH NOTE: All the problems listed in this section are corrected in version 3.12. Some bugs that surfaced after the release of version 3.11 are correctable by runtime patches in the file MSKERMIT.PCH. Put this file in the same directory as your MSKERMIT.INI file, and the patches will be installed automatically each time you start Kermit. Patch #1 (optional): Supply a different video mode for the Orchid Designer Professional VGA board when switching to 132 columns. As distributed, this patch is commented out. Dump screen via Ctrl-]F turns on LOCAL-ECHO. Corrected by Patch #2. Problem with cursor indexing in scrolling region setup. Fixed by Patch #3. Problems with matching curly braces in commands. Fixed by Patch #4. Various reports requested by VT320 escape sequences from the host are not furnished. Fixed by Patch #5. Transparent printing problem: MS-DOS Kermit does not properly respond to CSI 4 i to terminate transparent printing when the CSI is sent in 8-bit form. Fixed by Patch #6. Inability to transfer files on SET PORT TCP/IP connections when PARITY is EVEN or MARK. Fixed by Patch #7. VT220/320 DEC User Definable Keys, downloaded via escape sequences from the host, were being defined incorrectly. Fixed by Patch #8. The new release (2.2/R8) of Interconnections Inc's TES program crashes Kermit and requires the PC to be rebooted. Patch #9 is a workaround for this problem. The TES bug also prevents correct reception of 8-bit characters. Temporary workaround: tell the host not to send 8-bit data (e.g. SET TERMINAL /NOEIGHT in VAX/VMS). USING MS-DOS KERMIT ON LOW-END PCs Original 4.77 MHz PCs (PC, PC/XT) operate at lower processing speed than modern PC models, and can not support high communication speeds (9600 bps, 19200 bps, 38400 bps, depending on the exact configuration), unless both MS-DOS Kermit is configured to use XON/XOFF software flow control or RTS/CTS hardware flow control, and the computer or device with which MS-DOS Kermit is communicating also supports, and is configured to use, the same kind of flow control. It is possible to boost the performance of a low-end PC by installing a 16550 UART in place of the original 8250 if your serial board has a socketed (removable) UART chip. The 16550 incorporates an internal hardware buffer to reduce the amount of interrupts that must be serviced by MS-DOS Kermit. MS-DOS Kermit fully supports the 16550 UART's buffering capabilities. MS-DOS 5.0 Reportedly, Kermit can lose incoming characters at high speeds (19200, 38400, etc, depending on CPU model). DOS 5.0's new memory management functions might be causing interrupts to be lost. If the serial port data-ready interrupt is not delivered to Kermit, Kermit never knows that a character has arrived and therefore does not read it. This problem has been reported by some users, while most other users report no problems at all operating at high speeds with DOS 5.0. MICROSOFT WINDOWS, DESQVIEW, OS/2, ETC Although MS-DOS Kermit can work in these environments, and even takes advantage of many of their features, it does not have a "graphical user interface". You still have to type commands to the MS-Kermit> prompt or execute them from command files with the TAKE command. OS/2 1.x... Under OS/2 1.3 and earlier, MS-DOS Kermit only runs in full-screen mode. Under 1.x of OS/2, the serial port must first be conditioned by the command: SETCOM40 COM1=ON OS/2 2.0... MS-DOS Kermit can run in a window of OS/2 2.0. Under OS/2 version 2.0, Kermit's flow control reportedly has no effect because OS/2 itself is doing the buffering. You can configure OS/2 to handle flow control itself by adding a command like the following to your STARTUP.CMD file: MODE COM1 XON=ON (for XON/XOFF software flow control) or: MODE COM1 RTS=HS OCTS=ON (for RTS/CTS hardware flow control) If your PC's communication port is a 16550A[NF] UART serial communication adapter (as is standard on the PS/2), it has a built-in buffer to improve performance. To enable use of the 16550's buffering capability, add BUFFER=ON to your MODE command: MODE COM1 XON=ON BUFFER=ON (for XON/XOFF software flow control) or: MODE COM1 RTS=HS OCTS=ON BUFFER=ON (for RTS/CTS hardware flow control) IDLE_SENSITIVITY should be set to 0 and IDLE_DETECTION_TIME should be 100 to reduce the jerkiness of DOS sessions. By all accounts, massive amounts of memory (at least 8MB, and the more the better) are required for successful operation of MS-DOS Kermit or ANY communications software written for DOS in order to prevent the software from being swapped out while characters are arriving at the serial port. On OS/2 systems with small amounts of memory, characters are can be lost during terminal emulation and file transfer, especially at high communication speeds. It is also reported that other commands, particularly script programming and macro commands which allocate memory dynamically, fail in bizarre ways. These problems have been reported to IBM and hopefully a solution will be found. Meanwhile, here are some suggested workarounds: 1. Install more memory in your PC, bringing it up to 8MB or more. 2. Remove the line IFS=HPFS.IFS from CONFIG.SYS. 3. Run Kermit at a lower communication speed. 4. Use the MODE command to have OS/2 perform the desired type of flow control. 5. Configure Kermit to use the minimum amount of memory for rollback screens, etc. ("SET KERMIT=ROLLBACK n" DOS environment variable). IBM suggests running Kermit in a true DOS 5.0 Session instead of the VDM to allow direct hardware access, but reportedly this does not help because of problems in OS/2's COMM.SYS and VCOMM.SYS drivers. (Perhaps it helps if these drivers are not loaded). The VCOMM.SYS driver is certified by IBM to work at speeds up to 2400 bps, but reportedly it has trouble even at this low speed. Other hints for those who are experiencing buffer overruns or other data loss: For file transfer, use small packet sizes and a window size of one. During terminal emulation, avoid host-initiated printing. TCP/IP (and presumably other networks supported by MS-DOS Kermit) cannot be used with OS/2. OS/2's network interface, the Communication Manager, is totally different from the methods (such as Packet Drivers) known to Kermit. If Novell provides a Virtual ODI Driver (VODI.SYS?) for OS/2, MS-DOS Kermit 3.12 or later should be able to operate in this environment with its new built-in ODI support. WINDOWS... You can't run Kermit in a Microsoft Windows 3.0 window except on a 386-class machine in running Windows in Enhanced Mode, which generally requires that your PC have at least several megabytes of main memory. Under Windows 3.0 Real or Standard mode, you can use still use MS-DOS Kermit as a full-screen DOS application. Kermit works in a window on all PCs (if they have enough memory) under Windows 2.0. Reportedly, a third-party communication port driver (such as TurboComm) might be needed to run Kermit at speeds greater than 9600 bps under Windows 3.0. A 16550a UART helps too, for its FIFO buffering. Other reports indicate that high speed operation is possible after all, and suggest looking at the Windows files SYSIN*.TXT for information about SYSTEM.INI settings related to communication ports, particularly COMxBuffer and COMBoostTime. Still other reports say that Kermit runs fine in a window at 19200 bps without losing any characters, as long as a good flow control method (such as RTS/CTS) is in effect. The real answer is a combination of software, BIOS, machine architecture, serial port hardware, which drivers and TSRs are loaded, system load, and Windows settings. When running Kermit in two windows at once, one on COM1, one on COM2, Windows complains that both applications want to access COM1. To make sure that COM1's IRQ 4 is not touched when starting COM2 (part of the "find the IRQ" test), specify the COM2 port parameters explicitly as SET COM2 \x2f8 3 (standard port address and IRQ for COM2) to make Kermit skip the test. The use of COM3 and COM4 under Windows is problematic, but most users report success after finding the right "SET COMx <address> <irq>" command. When running MS-DOS Kermit under any version of Windows, specifying a ",P" at the end of a serial port setting in WIN.INI or in a MODE command can cause loss of characters from the serial port. Remove the ",P" from the setting. WINDOWS AND TCP/IP... To use Kermit's TCP/IP support under Windows 3.0, you either must set up the KERMIT.PIF file to "Lock Application Memory" (Enhanced-Mode Advanced options screen), or else run the WINPKT "shim" in addition to (and after) your packet driver. WINPKT should be given a lower software interrupt number than your packet driver, for example (using a Western Digital Ethernet board): WD8003E 0x61 0x7 0x280 0xca00 WINPKT 0x60 0x61 IPX NETX The order is important: start the packet driver first at interrupt 0x61 (or higher). Then start WINPKT, telling it to use interrupt 0x60 to talk to application software, and 0x61 to talk to the actual packet driver. After loading WINPKT, you can optionally load Novell or other packet-driver-compatible network software. Only one copy of MS-DOS Kermit can make a network connection at one time under Windows. Here is a PIF configuration for Kermit that has proven successful for TCP/IP operation in a Windows 386 Enhanced-Mode window: Video Memory: High graphics Memory: 320 640 Display: Windowed Execution: Background Close Window on Exit Foreground/Background: 100 or 150 Detect Idle Time Lock Application Memory (or don't lock application memory if WINPKT loaded) Monitor nothing ports Emulate Text Mode Retain Video Memory DESQVIEW and DESQVIEW/X ... Users of DESQview set "Optimize Communications" in the Advanced menu to "No". DESQview/X reportedly requires that the serial port be configured to "optimize" to prevent Kermit from losing characters. Network connections (TCP/IP over a packet driver or ODI) within an X window of DESQview/X apparently do not work. INCOMPATIBILITIES BETWEEN MS-DOS KERMIT 3.11 and 3.00/3.01: In version 3.11, "O" is not a sufficient abbreviation for OUTPUT because of the new OPEN command. If you have a script with "O" commands in it, it will fail. If you have exactly one macro defined that starts with "O", it is executed instead. Change abbreviations of OUTPUT from "O" to (at least) "OU". In version 3.12, "O" is accepted as a special abbreviation for OUTPUT. Macro arguments are now "stacked", saved at each macro entry and restored upon exit, so calling macro B from within macro A no longer destroys macro A's arguments. Macro definitions in 3.11 can be longer than before. Long macros that work in 3.11 won't necessarily work in earlier releases. The new macro argument \%0 now holds the name of the macro. The REPLAY command allows screen rollback, dump, print, etc. At the end of the replay file, use regular terminal emulation keys (PgUp, Ctrl-End, PrintScreen) to invoke these functions, and use Alt-X, Ctrl-]C, or Ctrl-C to get back to the prompt. Previously, any keystroke would return to the prompt. If an INPUT command is interrupted by pressing any key, the status is set to FAILURE, just as if the command had timed out. If you need to know whether an INPUT failed because it timed out or was interrupted, use a technique like this: SET ALARM 30 INPUT 30 Login: IF SUCCESS GOTO OK IF ALARM ECHO INPUT Timed out IF NOT ALARM ECHO INPUT Interrupted from keyboard ECHO no longer requires a \13 on the end. It supplies both CR and LF. The WRITE command, introduced in version 3.00, no longer accepts "objects" like DATE, TIME, etc. Now it is more like an ECHO command that includes a destination specifier: WRITE SCREEN, WRITE SESSION, etc. The argument in all cases is a line of text. This text may contain any kind of backslash codes or variables, including the new (to version 3.10) built-in \v(xxx) variables like \v(time), \v(date), etc. Old-format WRITE commands will produce undesired results. For example WRITE SCREEN TIME FOO will print "TIME FOO" on the screen rather than something like "12:34:56 FOO". BYE, FINISH, or LOGOUT commands that fail (e.g. because the remote server has these operations disabled) no longer behave as if they had succeeded. Text and graphics screens can now have separate colors. Host-generated autoprint sequences work differently. In version 3.01 and earlier, MS-DOS Kermit copied characters to the printer as they arrived, regardless of the screen dimensions. In version 3.10 and later, Kermit's action follows that of a real VT terminal: it waits until the cursor moves off the line with a linefeed or formfeed, or the line wraps. If your screen does not support 132 columns, Kermit wraps long lines -- even those destined for the printer during autoprint sequences -- at 80 columns. If you need to direct long lines to your printer under these circumstances, use transparent print instead, or else LOG SESSION PRN and then print the log. The Alt-minus key no longer "toggles" among all of Kermit's terminal types. As of version 3.11, Alt-minus switches between the Tektronix graphics screen and the text screen for the current text terminal type (e.g. VT320). DIALING The DIAL command and dialing directory have been totally redone for MS-DOS Kermit 3.11. See KERMIT.HLP (MSKERM.HLP) for a description. If you need to dial a non-Hayes compatible modem, write a dialing script for it, and change the definition of the "_modem" variable in MSKERMIT.INI. See MSIROLM.SCR for an example: a dialing script for the IBM/Siemens/Rolm CBX. SERIAL COMMUNICATIONS On IBM PCs and PS/2s with IBM asynchronous adapters, Kermit can be used at speeds up to 57600 bps under DOS (under Windows or DesqView, the maximum speed is probably lower). 115200 bps works only with a very short shielded cable, and the async adapters of the two machines in perfect tune. Some VAX serial port interfaces are out of tolerance at 19,200 bps and faster. If your speed is set too high, the symptom might be lost or garbled characters or graphics images on the screen, or data-overrun beeps. Normally flow control prevents these problems so use it if you can. Printing while in CONNECT mode needs flow control to be active. MS-DOS Kermit does not monitor the communication line for carrier loss during terminal emulation or file transfer. You can SHOW MODEM or SHOW COMMUNICATIONS to inquire about CD, DSR, and CTS. The script command WAIT permits sensing carrier presence in a script program. The SHOW MODEM and WAIT commands work right only if your modem or other communication device is configured to raise and lower the DSR, CTS, and CD signals appropriately, and the cable that connects your PC to the modem passes these signals through. For some modems, the factory setting is to always keep CD on, even if there is no connection. Consult your modem manual. For RS-232 devices, the HANGUP command (and Ctrl-]H in CONNECT mode) works only if the cable that connects your PC to the communication device passes the DTR signal through, and if the communication device itself is configured to hang up or otherwise terminate the connection when the DTR signal is lowered by the PC. For some modems, the factory setting is to ignore DTR transitions. Consult your modem manual. NOTE: in version 3.11, the HANGUP command turned off DTR for about 1/2 second and then turned it back on again. In version 3.12, the HANGUP command turns off DTR until the next time you issue a command that accesses the serial port. When communicating across some network pathways, the longest burst of information tolerated from the PC can be rather short. For example, the LAT path with SET PORT DECnet has a limit of 256 bytes and the SET PORT TES path has a limit of 512 bytes in a burst. Longer bursts can cause the network software to drop the connection. This is important when sending files, and if sliding windows are active, the sum of all the packets in the window (packet length times the number of window slots) must be shorter than the above limits. This is not a Kermit problem. TERMINAL EMULATION Kermit's VT320/340 emulator lacks the following features: . Smooth scroll . Downloadable soft fonts . ReGis graphics (VT340/330) . Dual sessions in split screens (VT340/330) . Local screen editing and block transmission (for security reasons) . ENQ/Answerback (also for security reasons) . True double height/width characters (these are simulated) . Selective erasure (as a character attribute, a formatted screen item) . Many of the exotic and rarely used features of the DEC VT340/330 series: mostly formatted screen and graphics operations highly specialized to DEC hardware. On certain "national keyboards", like the German keyboard, Kermit's normal escape character, Ctrl-] (Control-Rightbracket) does not appear to work. This is because IBM changed the way certain control characters are typed on these keyboards. On the German keyboard, Ctrl-] is produced by holding down the Ctrl (Strg) key and pressing the + (plus) key. MS-DOS Kermit has no way of knowing this, and continues to display the escape character as "^]". Kermit does not work with certain Swedish keyboard drivers because of a bug in the keyboard driver. Workaround: use a different keyboard driver. Reportedy there are several different Swedish keyboard drivers available. If VAX/VMS thinks you have a VT220 or VT320, it sends 8-bit control sequences. Kermit does not understand them unless you SET TERMINAL BYTESIZE 8. The symptom is the appearance of fragments of escape sequences on the screen and wrong cursor positioning, and possibly fractured tab settings, particularly during EVE sessions. You can prevent VMS from sending 8-bit control sequences (if you really do not have an 8-bit connection) by giving the VMS command SET TERMINAL /NOEIGHT. For VAX/VMS, you should also use Xon/Xoff flow control in both directions (SET TERM /TTSYNC /HOSTSYNC on VMS). In VT100/200/300 emulation on the IBM PC family, receipt of ESC [ 4 m (turn on underscore) results in reverse video rather than underscore on IBM CGA, EGA and other color displays. IBM display adapters have one less attribute than DEC monochrome terminals, and in addition the two systems intensify dots differently (IBM does foreground/character dots only, whereas DEC can illuminate any dot). SET TERMINAL COLOR 1 [3xx 4xx] (used to make the foreground color bright), if issued when SET TERMINAL SCREEN REVERSE is in effect, reverts to normal video. If certain incomplete escape sequences (e.g. Operating System Command) are received during terminal emulation, Kermit can hang waiting for the string terminator that never comes, usually because of noise on the communication line. Reset the terminal emulator by pressing Alt-= (Alt-equals), the default key for \Kreset. Kermit does not support 132-column mode on the IBM monochrome adapter, CGA, MCGA, or EGA. However, if your display adapter handles 132 columns in text mode, and Kermit knows how to control it, Kermit can switch automatically between 80- and 132-column mode upon host command or SET TERMINAL WIDTH { 80, 132 }. Otherwise you can provide external commands for changing the width in the files COLS80.BAT and COLS132.BAT. Kermit does not support other widths (except, to a certain extent, 40). Kermit assumes 25 screen lines but can adapt to other lengths if it knows how to get this information from the video adapter. There still might be some confusion about screen length when switching between text and graphics modes, or between 80 and 132 column mode, or escaping back from CONNECT mode, due primarily to lack of reliable or consistent information from the many different kinds of video adapters. The following video boards are directly controllable by Kermit for changing screen width: ATI EGA and VGA Wonder AST, Dell, and other boards based on Western Digital VGA boards AT&T / Olivetti Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe IBM XGA Paradise AutoSwitch EGA Mono Paradise Professional Paradise VGA Plus 16 (ROM BIOS 003056-xxx firmware) Paradise VGA Plus (ROM BIOS 003056-xxx firmware) Paradise VGA Professional (ROM BIOS 003056-xxx firmware) Paradise VGA1024 STB VGA/EM (Tseng TVGA) STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus Tseng Labs EVA board with 132-column kit installed Tseng Labs UltraPAK mono/Hercules with 132 column modes Video 7 Vega Deluxe with 132X25.COM driver installed and Video 7 VGA For other boards, create COLS80.BAT and COLS132.BAT files. If your video board and monitor can't do 132 columns in text mode, neither can Kermit. If you have a monitor with fixed horizontal frequency but a video adapter that Kermit knows how to switch into 132 column mode, you will see only garbage on your screen whenever Kermit switches to 132 columns. There is no way to tell Kermit to ignore "switch to 132 columns" commands. If you buy a 132-column-capable video adapter, be sure you have a compatible monitor. To get properly formatted screens during terminal emulation, be sure to inform the remote host of your screen width and length. So that key translation and macros can work on both IBM and non-IBM compatible PCs, Kermit uses the system BIOS to obtain key scan codes. But the IBM BIOS does not produce scan codes at all for certain keys, and may produce duplicate scan codes for others. Num Lock, Scroll Lock, Pause are examples. When you PUSH to DOS (including when you use Kermit's RUN command), and you have XON/XOFF flow control enabled, Kermit sends an XOFF (Ctrl-S) to the host when you leave, and XON (Ctrl-Q) when you return. This prevents data transmitted by the host from being lost. However, if you do this while using the EMACS text editor on the host, the Ctrl-S will be interpreted as a Search command, and the Ctrl-Q as a Quote command. When you return to EMACS, type several Ctrl-G's to get back to normal. Similar comments about sending Xoff and Xon apply when Kermit is commanded to change its screen size between 80 and 132 columns. Session logging can be turned on using the LOG SESSION command, and it can be toggled on and off during terminal emulation by using whatever keys are associated with the verbs \Klogoff and \Klogon. One user stated the requirement to enable a session log, but to have it initially turned off. This can be done as follows (using the F1 and F2 keys as examples): SET KEY \315 {\Kloginit} ; F1 to turn on log SET KEY \316 \klogoff ; F2 to turn log off DEFINE loginit log session, set key \315 \klogon, define loginit, connect To log your session to a printer, add the word PRN after "log session" in the third line above. The session log is written to disk by DOS. The frequency with which DOS updates this file is governed by the BUFFERS= line in your CONFIG.SYS file (see your DOS manual). If you allocate a large number of buffers in CONFIG.SYS, disk operations occur infrequently and this improves performance. If you need to have the session log updated more frequently to minimize the loss of data when there is a power failure, you can do this (at the expense of efficiency) by allocating a smaller number of buffers in CONFIG.SYS. GRAPHICS TERMINAL EMULATION If your display adapter lacks sufficient memory (as do CGA and the early 64K EGA boards), then when you switch away from a graphics screen, or type the connect-mode escape character (Ctrl-]), the graphics image is lost. Furthermore, certain graphics images may be overlaid with vertical stripes on small (64K) EGA systems. PS/2 Model 25 and 30 MCGA adapter is used in low-resolution CGA mode by default; images may be elongated or truncated. Hi-resolution graphics can be done (as of version 3.11) via SET TERM GRAPHICS VGA, but the PC might not be able to keep up at speeds above 9600 bps. When you type the escape character (normally Ctrl-]) while in Tektronix graphics mode, the screen goes back to text memory. Then when you type the argument character, the graphics screen reappears (unless the argument was C or P). Ctrl-]F will not file the graphics screen, but rather the text screen, because that's the screen that's showing after type the Ctrl-] key. To file the graphics screen (in TIFF format), use \Kdump (normally on Ctrl-End). You can't dump the Tektronix screen while the GIN-mode crosshair cursor is active; Kermit's keyboard translator is not active. Key strokes (of regular typewriter keys) or mouse actions are used to transmit the crosshair coordinates. If you press a non-typewriter key, Kermit just beeps. Kermit does not emulate a particular kind of color graphics terminal, such as a DEC ReGIS display or a Tektronix 41xx or 42xx series. However, it can be used for color graphics by mixing ANSI color-setting escape sequences with Tektronix or Sixel commands. This requires graphics software vendors adding support for MS-DOS Kermit graphics to their packages (so far, WordPerfect Corp has done this for their host-resident products). There is at least one ReGis-to-Sixel converter on the market: RETOS, a DEC product for VAX/VMS. Problems may occur when using Kermit with host-resident (VAX/VMS) versions of WordPerfect because the color palette report sent upon request of WordPerfect is very long. If the host is not configured properly, parts of the report will be lost because of overruns on the VMS side. SET TERM /HOSTSYNC and /TTSYNC are required for WP/VMS. Even then intervening communication boxes (e.g. terminal servers) can become overloaded with the 200++ byte response. PRINTER SUPPORT (Shift-)Printscreen can cause the PC to hang if there is no attached printer. This is a BIOS feature, Kermit never receives the command. If this happens during terminal emulation, try pressing Alt-= (hold down Alt and press the "=" key) several times to reset the terminal emulator. Serial printers are not directly supported. Kermit does not do flow control between itself and a serial printer. To use a serial printer effectively, you must have a driver for it that takes care of flow control, such as MSPSPD, available on the MS-DOS Kermit Utilities and Technical Documentation diskette. Transparent printing starts when the host sends the sequence ESC [ 4 i and stops when the host sends ESC [ 5 i. All characters, including escape sequences, that arrive at the port are passed directly to the printer without translation (but the parity bit is stripped if Kermit's parity is not NONE). If character translation is desired, or it is desired not pass screen-control escape sequences to the printer, use Autoprint rather than Transparent print (ESC [ 0 i, ESC [ ? 4 i, ESC [ ? 5 i). In that case, characters are translated to the current IBM code page. If your printer doesn't support your IBM code page, you need an external utility to translate from the PC code page to the printer's character set. You can use SET PRINTER xxxx to capture Transparent print or Autoprint data into a file. INTERNATIONAL CHARACTER SETS In MS-DOS Kermit 3.01 and later, SET TRANSLATION INPUT has been extended to work with character sets in which the C1 range (80h-9fh) contains graphic, rather than control, characters, but only if you SET TERMINAL CHARACTER-SET TRANSPARENT. MS-DOS Kermit 3.01 changed the strategy used by SET TRANSLATION INPUT and which is described in the first edition of "Using MS-DOS Kermit". In version 3.00 and earlier, the command worked like this: SET TRANSLATION INPUT \xxx \yyy where \xxx is the code for the character received at the communication port, and \yyy is the code for the character to display on the screen. In version 3.01 and later, \xxx is the code for the character that would be displayed on the screen in the current code page after normal translation, rather than the untranslated character that arrives at the port. Example: modifying the built-in Swedish character set to show selected character values as ASCII rather than Swedish characters (using PC code page 437) is now done like this: SET TERMINAL CHARACTER-SET SWEDISH SET TRANSLATION INPUT \144 \64 ; What would normally be E-acute is atsign SET TRANSLATION INPUT \154 \94 ; U-diaeresis is circumflex SET TRANSLATION INPUT \129 \126 ; u-diaeresis is tilde SET TRANSLATION INPUT \130 \96 ; e-acute is accent grave SET TRANSLATION INPUT ON ; Enable translation Translations depend on the current code page, and Kermit asks DOS for this information. Code pages exist which are not distributed in the USA, such as CP861 for Icelandic and CP862 for Hebrew. It is said that DOS incorrectly reports these code pages to be CP437. It's not clear what the DOS code page reporting mechanism would be, if any, for otherwise IBM-compatible PCs fitted with special character sets such as Cyrillic, Arabic, etc, so in these cases Kermit assumes CP437 and again, there is no method for the user to load the necessary character set translation tables for file transfer. Code page switching is reportedly not possible on old PC/ATs with small-memory (64K) EGA boards, nor with DOS versions earlier than 3.30. In MS-DOS Kermit 3.0 and 3.01, the right hand portion (GRight) of the Latin1 terminal character set won't be accessed by SI/SO locking shifts unless Kermit first receives the escape sequence ESC-A (Escape, dash, uppercase A) from the host. This is the way Digital Equipment Corporation designed the VT300 terminals. The initial state is G0 = G1 = ASCII, G2 = G3 = Latin1, and SI (Control-N) shifts the GLeft pointer from the G0 to the G1 set. The escape sequence ESC-A puts Latin in G1. Alternatively, the right hand portion is accessable by using Single Shift 2, ESC N, or Locking Shift 2, ESC n, before the text character(s). In MS-DOS Kermit 3.10 and later, you can also designate Latin-1 to G1 (so that SO/SI will work) by hand with the MS-DOS Kermit command: SET TERMINAL CHARACTER-SET LATIN1 G1 Kermit's terminal emulator sends characters with their 8th bit set as ESC N <character without the high bit> if parity is other than NONE (version 3.12 has extended this mechanism; see MSR312.UPD). LOG SESSION records the characters that arrive at the serial port, before translation by either Kermit's built-in terminal character set translation tables or by user-specified SET TRANSLATION INPUT commands (versions 2.32/A and earlier did apply the SET TRANSLATION INPUT command before logging to disk). This allows the REPLAY command to work correctly, but it prevents special characters from being logged after translation to the PC's own character set. Screen dump (Ctrl-End or Ctrl-]F) and autoprint, however, record the translated characters. SET TERMINAL CHARACTER SET is effective only for text screens, not for graphics screens. This is because the fonts for all the special characters have not been designed yet (and may never be, and even if they are, they would require a lot of memory). International characters in macro names are not case independent. Case-independent string matching operations (e.g. SET INPUT CASE IGNORE, IF EQUAL xxx yyy) won't necessarily work with international characters. COMMAND PROCESSING A command file that contains lines or commands that are too long for DOS's line buffer (usually 128 characters) can hang your PC. The maximum size for a Kermit prompt string (SET PROMPT) is 60 characters. However, Kermit does not complain if you use a longer one. A work buffer is overwritten, but the next time it is used, the effect on your prompt is unpredictable. (Fixed in 3.12) Question-mark help is not available while typing a numeric field. Commands in TAKE-files or MSKERMIT.INI can be continued by including "-" as the last character on the line, but NOT if the line ends with a trailing comment. In other words, you can't have a trailing comment on a continued line. If you need to end a line with a dash, but this dash is to be part of the command rather than a continuation symbol, then use \45 instead or add a trailing comment. Trailing comments can be used only in command files. All text starting with the first semicolon through the end of line is ignored. If you need to include an actual semicolon in a command, precede with a backslash (\;). The name and password that you specify in SET SERVER LOGIN must be matched exactly by the ones in REMOTE LOGIN. Alphabetic case matters. If you need to include spaces within the username, password, or account field of the REMOTE LOGIN or SET SERVER LOGIN commands, surround the field with {braces}. FILE TRANSFER MS-DOS Kermit does not create zero-length files. If a zero-length file is sent to MS-DOS Kermit, it will not be created on your PC's disk. SET EOF CTRL-Z, when used with text files which actually contain Ctrl-Zs, might result in gaps or truncation in the vicinity of the Ctrl-Z. This is a DOS "feature". When using Kermit through a terminal server (particularly those that execute the TCP/IP Telnet protocol), or directly through a SET PORT TCP connection, it is sometimes necessary to SET PARITY SPACE in order to transfer files. It is sometimes impossible to use very long packets with terminal servers. Try SET RECEIVE PACKET-LENGTH 80, working up or down to the longest length that works. REMOTE TYPE and other REMOTE commands resulting in an error "Unable to open CON": insufficient FILES= in CONFIG.SYS. FILES= should be at least 20. MS-DOS Kermit uses the program named in the DOS Environment command line starting as SHELL= as a replacement for COMMAND.COM. Such a line is seen by typing SET at the DOS prompt, and it is not associated with the SHELL= line appearing in file CONFIG.SYS. The MS-DOS Kermit command REMOTE SET BLOCK-CHECK will generally have no effect upon a remote server. SET BLOCK-CHECK locally within MS-DOS Kermit. The host prompt for TRANSMIT is a single character (SET TRANSMIT PROMPT). It is not possible to specify a multi-character or variable prompt. SCRIPT PROGRAMMING The terminal emulator is not active during execution of script commands such as INPUT and OUTPUT. This means: 1. If the host sends the escape sequence that tells the terminal to identify itself, it is ignored. You have to put the appropriate INPUT and OUTPUT commands in your script program. Here is a macro to set your terminal type in Kermit and to set up the appropriate response string as well as terminal type string: def term if not def \%1 def \%1 vt320,- set term type \%1,- if error end 1,- assign _ttype \%1,- if eq \%1 vt320 assi _tid \27[\63\;1\;2\;4\;8\;9\;15c,- if eq \%1 vt220 assi _tid \27[\62\;1\;2\;4\;8\;9\;15c,- if eq \%1 vt102 assi _tid \27[\63\;6c,- if eq \%1 vt100 assi _tid \27[\63\;1c,- if eq \%1 vt52 assi _tid \27/Z Whenever you switch terminal emulations, do "term vt102" instead of "set term type vt102" (substitute your preferred terminal type). In any script that responds to ESC Z (or whatever), have it "output \m(_tid)", and any prompt that asks for your terminal type you can "output \m(_ttype)". And be sure to execute a "term" command in your MSKERMIT.INI file, so your initial terminal type is set. 2. A host-generated escape to put the terminal in Tektronix mode has no effect. Put explicit SET TERMINAL TYPE TEK commands in the appropriate places in your script program. 3. Screen formatting escape sequences have no effect. If you have SET INPUT ECHO ON, they are simply displayed as-is. If the remote host is sending ANSI (VTxxx) escape sequences during execution of the script program, then users of IBM PCs can use the ANSI.SYS or similar console driver to interpret the escape sequences. This is particularly useful when running a script that logs in to a full-screen system, such as an IBM mainframe through a protocol converter. But beware: ANSI.SYS is not totally compatible with Kermit's VT emulator, and it may produce unwanted side effects, the most annoying of which is suddenly popping your PC into 40-column mode! If you experience difficulties with your screen display while using Kermit script programs, use SET INPUT ECHO OFF. Or remove ANSI.SYS from your CONFIG.SYS file and reboot. PAUSE, WAIT, and similar commands also cause port input to be echoed to the screen if INPUT ECHO is ON. Use SET INPUT ECHO OFF to defeat this effect. Script programming hint: To test whether a readable floppy disk is available in drive A:, do this: SPACE A: IF FAILURE ECHO No diskette in drive A:. The ON_EXIT macro is intended only for automatic execution when the MS-DOS Kermit program exits. It only works once, to prevent recursion (as would happen, for example, if you put an EXIT command in your ON_EXIT definition). If you invoke the ON_EXIT macro explicitly during a Kermit session, you won't be able to use it again. HARDWARE RELATED PROBLEMS Do not use the QEMM v6 "Stealth (ST:M) optimization" with Kermit. This prevents Kermit from accessing your video board's BIOS memory and finding the video board's signature, and therefore from determining the appropriate method for switching between 80 and 132 columns. There have been isolated reports that MS-DOS Kermit (3.11 as well as earlier versions) crashes with "Divide Overflow" errors on certain 486-based machines such as the AST Bravo 486. This problem is currently unresolved. Kermit is known to work properly on the Dell 486, and it contains no instructions that require any kind of processor higher than an 8086/8088. Reportedly, this problem is not specific to Kermit; Microsoft Windows is said to crash on the same machine if the BIOS cache memory is enabled, but works OK (but about 3 times slower) if the cache is disabled. MS-DOS Kermit does not necessarily work with all brands of internal modems, particularly some of the built-in ones that come with laptop PCs from various makers. If you can't communicate satisfactorily through such a modem, you can use the new command SET COM1 <address> [ <irq> ] (also SET COM2 .. COM4) to identify the port's hardware address and interrupt request line number. USE THIS COMMAND WITH CAUTION, AS IT MIGHT INTERFERE WITH YOUR PC's NORMAL OPERATION! If all else fails, give the command SET PORT BIOS1 (or 2, etc) and try again, to access the port through the system BIOS -- this is much slower that direct hardware control by Kermit. Kermit does work with most popular brands of internal modem (such as the Hayes Smartmodem 1200B and 2400B), and with all known external (ASCII, not Baudot) modems, both direct-connect and acoustic. When using a COM3 or COM4 port whose address and IRQ differ from Kermit's defaults, be sure to issue the SET COM3 (or SET COM4) command before SET PORT COM3 (or COM4). Kermit does not work properly with revision C of the "built-in" (not "internal") modem in the Toshiba T1600 laptop computer. Revision F does not have this problem. Add-in CPU boards might not handle UART serial port details properly if the UART is not directly part of the add-in cpu board. One symptom will be Kermit can send but not receive characters. Try SET PORT BIOS1. Reportedly MS-DOS 2.11 for Tandy 1200 machines has an internal problem if a program opens device CON for output, as Kermit does for REMOTE commands. The symptom is cross linkage of files on the current disk. This has not been noted with other versions of MS-DOS 2.11. Solution: upgrade to a more recent version of DOS. INTERACTIONS WITH DOS On early (original motherboard & BIOS) PCs, and on systems that mimic them (e.g. early Compaqs), the cursor may assume a strange shape upon return from CONNECT mode. This is caused by a bug in the early BIOS, which stored cursor attributes incorrectly. The PC Tech Journal article "The Dashed Cursor", by Paul Pierce, PC Tech J., Dec. 1985, page 47, suggests the following fix: code segment public 'code' assume cs:code, ds:code, es:nothing ; ; This program is set up to be made into a COM file ; org 100H ; ; First check for the monochrome adapter. ; start: int 11H ; set ax = equipment flag and al,30H ; mask off all but video bits cmp al,30H ; test for monochrome adapter jne exit ; jump if not monochrome ; ; Now check for incorrect cursor mode returned from the Bios ; mov ah,3 ; call bios to get cursor type int 10H ; cmp cx,0607H ; check for invalid (color) type jne exit ; jump if not a bad value ; ; At this point we know that the monochrome adapter is in use and that the ; BIOS cursor mode is wrong. Call the BIOS to fix the cursor type. ; mov cx,080cH ; use correct cursor type mov ah,1 ; call bios to set it int 10H exit: mov ah,0 ; exit back to DOS int 21H code ends end start A REMOTE HOST or similar command sent to an MS-DOS Kermit server can invoke the DOS critical error handler, which issues its familiar "Abort, Ignore, Retry?" message on its real screen, and is waiting for a response from its own real keyboard, and so the server will no longer respond. Kermit attempts to catch many of these errors before DOS learns learns about them, but some cannot be avoided (like disk i/o errors). Interaction between MS-DOS Kermit and various terminate-and-stay-resident (TSR) programs is necessarily unpredictable, depending upon how "well behaved" they are. Certain console, mouse, clock, or graphics drivers might interfere with file transfer, for example the CMOSCLK.SYS driver on the PS/2 model 55SX. If TSR programs are interfering with Kermit (by taking over the timer or serial port interrupts), you should remove them all from your AUTOEXEC.BAT or CONFIG.SYS files, and then put them back one by one until you have identified the one that's causing the problem. Caution should be used when invoking certain TSR programs while PUSHed from Kermit (e.g. using the PRINT command for the first time), as not all of these programs observe proper etiquette for allocating and freeing memory, and more importantly the TSRs will be loaded above Kermit into the middle of memory where they may prevent large programs from loading later. NETWORKS Sending BREAK over network connections via SET PORT BIOS1 + Int 14h interceptor may or may not work, depending upon the actual network and drivers in use. Kermit uses the BREAK facility if the driver and network support it. Symptom: PC no longer works after installing a network board. Diagnosis: a 16-bit VGA display adapter is running in 16-bit mode. Cure: Jumper it back to 8 bits and all should start working again. PC-NFS prevents applications programs such as Kermit from creating a file in the root directory of a PC-NFS disk drive. When the applications program asks if a particular file exists in the root, PC-NFS always responds with "volume label present", whether or not the actual file is present. SET PORT TELAPI performance is good with version 4 of Novell's LAN WorkPlace for DOS but it is poor with version 3.5 because that older version sends each Kermit byte in an individual packet. (Should be fixed in 3.12) The Interconnections TES product, which Kermit fully supports, has a fancy menu that pops up if you type the TES "hot key", Alt-LeftShift-T. Reportedly, this pop-up menu interferes with the LK250 driver that is distributed with Kermit (it works fine with regular IBM keyboards). The LK250 driver uses a special interrupt, and the TES menu program might not properly chain this interrupt. The workaround is to use TES's text-mode menu, which Kermit brings up if you type Alt-n during terminal emulation. MS-DOS Kermit 3.11 LAT connections do not work with PATHWORKS 3.0. They do work, however, with PATHWORKS 2.0 and 4.0. Workaround: for PATHWORKS 3.0, use CTERM connections instead of LAT. (Fixed in 3.12) For DECnet/DOS (PATHWORKS) LAT connections, it is often necessary to tell the LAT control program on the PC to reserve enough memory for all of the local LAT host names. By default, space for 16 names is allocated. Increase your LAT control program's memory allocation if you have more than 16 hosts on your DECnet network. Also, remove ALL permanent LAT names from your database and let the network provide them (this can mean waiting a minute or two for all broadcasts to be heard). Connections via Kermit's built-in LAT support do not work when LAT is loaded into EMS (expanded memory) under Microsoft Windows 3.0. Load LAT into conventional memory. (Should be fixed in 3.12) Reportedly, "set port decnet <node> <password>" doesn't work for LAT connections when a password must be specified. NETBIOS STATION-TO-STATION CONNECTIONS The procedure for establishing a NETBIOS PC-to-PC connection is as follows: 1. On the first PC: SET NETBIOS NAME <xxx> SET PORT NETBIOS SERVER 2. On the second PC: SET PORT NETBIOS <xxx>.K ("<xxx>" is any name you choose, up to 14 characters in length.) Now you can initiate file transfer and other Kermit protocol operations from the second PC. If you want the two PCs to "chat" in terminal mode, send a FINISH command from the second PC (or type Ctrl-C on the first, server, PC), and then give the following commands to both PCs: SET TERMINAL NEWLINE ON SET LOCAL-ECHO ON CONNECT TCP/IP SUPPORT As of version 3.11, MS-DOS Kermit contains built-in TCP/IP and TELNET protocol support. This allows a PC equipped with an Ethernet or other network board that is connected to a TCP/IP network to communicate with any other node on the network, without requiring any additional TCP/IP software on your PC. You need an external Ethernet-style (Class 1) packet driver for your network interface board, or a SLIP Packet Driver, or a Novell ODI driver. With ODI, Kermit's Telnet operates across Ethernet (many frame kinds), Token Ring, Arcnet, and PCnet. Kermit does not contain built-in network device drivers. Packet drivers are available from network interface manufacturers, and also via anonymous FTP from Columbia University, host watsun.cc.columbia.edu [128.59.39.2], cd packet-drivers, get the READ.ME file, read it, and take it from there. These files, now called the Crynwyr packet driver collection, are also available from Columbia University via mail order. ODI drivers are available from makers of the LAN adapter and in some cases from Novell. See Novell archive "novlib" on Compuserve and on machines ftp.is.sandy.novell.com [137.65.12.2] and mirrors such as netlab2.usu.edu [129.123.1.44] for Novell supplied ODI drivers. The TCP/IP code in this version of Kermit has been tested successfully with the following boards and packet drivers (according to reports from users): Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1 3COM 3C501 with Clarkson 3C501 packet driver 5.0. 3COM 3C503 with Clarkson 3C503 packet driver 9.4.0. Western Digital WD8003E with WD8003E packet driver 9.7.0 Cabletron 2000 and 3000 series DNI boards with CSIPD_E 1.0x packet drivers on unshielded twisted pair, thin Ethernet, and thick Ethernet, on both PC/AT and Microchannel buses (don't use CSIPD_X 2.00). Micom-Racal NI5210 with NI5210 packet driver. AT&T EN100 with Clarkson AT&T packet driver. IBMTOKEN.COM 3C501 emulation packet driver 1.9 over various Token Ring boards and drivers. DIS_PKT over NDIS for LAN Manager networks and NDIS-compliant boards including SD8003, 3C503, AT&T 10MB/sec thinwire Harvard ODIPKT over LSL, LANSUP, and IPXODI over Ethernet (but not Token Ring) LocalTalk packet drivers are not supported, as they are not Ethernet-class Packet drivers. SLIP is supported in Version 3.12. The performance of the 3C50x packet drivers is poor, but the operation seems correct. Suggestion from a 3COM 3C503 Ethernet board user: "When installing the packet driver for 3Com 503 cards, one has to pay attention that the memory option on the card is not disabled. It was in my case, and the packet-driver did not complain. Since other drivers (e.g. the DEC PATHWORKS driver) do not require the memory enabled, the default is disabled." Reportedly, the packet driver supplied by Western Digital with their WD8003E and/or Elite network boards cannot be found by Kermit. The Crynwyr WD8003E packet driver, however, works correctly with both the WD8003E and Elite boards. To reconfigure a Novell network for packet drivers so Kermit and Novell software can be used concurrently, use special software developed at Brigham Young University, available via anonymous ftp from dcsprod.byu.edu. For further information, read the Kermit Distribution file MSABYU.HLP. An Ethernet-simulation packet driver is available for systems using the NDIS (Network Driver Interface Specification) program. NDIS is frequently used with Lan Manager networks, including AT&T's StarGROUP network and DEC's Pathworks for DOS. The interface program is named DIS_PKT and originated with FTP Software Inc. Their program DIS_PKT.GUP is available by anonymous ftp to vax.ftp.com, and a research version DIS_PKT9.ZIP is available from Utah State University by anonymous ftp to netlab2.usu.edu. Instructions for configuring Lan Manager to include DIS_PKT are included with the program. Kermit's TCP/IP support does not work over the Harvard ODIPKT driver on a Token Ring network because it requires Kermit to use Token Ring rather than Ethernet frames (but it does work with ODIPKT over Ethernet). Version 3.12 supports ODI directly, ODIPKT is not necessary except when using Windows. Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of Ethernet frames: DIX/Blue-Book/Ethernet_II, 802.2, 802.2 with SNAP, and 802.3, as well as with Token Ring, Arcnet, and PCLan broadband. No extra protocol "shim" is needed. The ODI interface will be tried if a Packet Driver is not found, and it can be selected in preference to a packet driver by the command: SET TCP/IP PACKET-DRIVER-INTERRUPT ODI where "ODI" replaces the interrupt number of a Packet Driver. For ODI, the file NET.CFG should have the lines "Protocol IP etc" similar to the example below: # File NET.CFG, example PB buffers=10 show dots=on Link Support buffers 6 1514 MemPool 2048 Link Driver SMCPLUS Port 280 20 Mem 000CA000 2000/10 Int 7 frame Ethernet_II Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II Kermit requires three "protocols", IP, ARP, and optionally RARP as shown above. The frame kinds can be anything the board will support: Ethernet, Token Ring, Arcnet, all IEEE 802.2-based frames etc. ODI will complain if the frame type cannot support these protocols. Arcnet uses different TYPE values, D4 for IP, D5 for ARP, and D6 for RARP, rather than 0800 etc, as per RFC-1201. There is the question of which board Kermit (or IPX or other application) will use if two or more boards are available. Although one would think the board could be selected by placing the Protocol IP, etc, lines under the desired Link Driver section, such is not really the case; those lines tell the LSL the frame kind to associate with the protocol (say IP) but not the board. The frame lines are associated with particular boards, however. The default method for finding a board is that the application chooses "the first board" offering a suitable frame, regardless of whether or not the Protocol IP, etc, lines are present for that board. "First" refers not to the contents of NET.CFG but to the order in which board drivers are loaded at DOS level. So the indented protocol lines tell ODI which frame a protocol needs, and a TYPE to use for recognizing packets, but the lines do not identify a particular board. To target a particular board a separate main section is used in NET.CFG. The section starts with the word Protocol against the left margin and has Bind indented beneath it, like this - Protocol Kermit indentifies Kermit section of NET.CFG bind SMCPLUS bind to SMCPLUS board driver When a board name is used more than once then the alternative form is to use a board number in place of the name: Protocol Kermit bind #2 bind to the board loaded second Kermit considers the text in these sections to be case insensitive. The #<digit> construction must not have a separation between the number sign (#) and the digit. The #<digit> case is normally used when two or more boards share the same driver and thus are not distinguishable by name alone. A sample STARTNET.BAT file might look like this. @echo off run quietly c:\lsl >nul LSL is always loaded before boards c:\smcplus.com >nul SMC/WD8003E board, the first c:\exos.com >nul EXOS-205T board, the second rem c:\odinsup Odinsup can coexist with Kermit rem c:\odipkt 0 96 Odipkt can coexist with Kermit c:\ipxodi >nul IPX is always loaded after boards rem echo Starting network... may be needed to help some drivers c:\bnetx ps=my-preferred-server > nul rem (Packet Burst mode) NETX loads after IPX @echo on If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the first loaded board, SMCPLUS, in the absence of a "bind" command. Putting the section "Protocol Kermit, bind <board name or number>" anywhere in NET.CFG selects a particular board for Kermit. A complete NET.CFG file using two boards is shown below: # File NET.CFG, an example with two boards PB buffers=10 show dots=on # all main sections must start in column 1, indent local material. # Protocol "IPX" is for Novell's IPXODI Protocol IPX Bind EXOS # Protocol "Kermit" is for MS-DOS Kermit Protocol KERMIT Bind EXOS Link Support buffers 6 1514 MemPool 2048 Link Driver exos Port 310 20 Mem 000D0000 400 Int 5 frame Ethernet_II Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II Link Driver SMCPLUS Port 280 20 Mem 000CA000 2000/10 Int 7 frame Ethernet_II frame Ethernet_Snap Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II # Protocol "TCPIP" is for Novell's Lan WorkPlace for DOS, not Kermit Protocol TCPIP ip_address 129.123.1.99 ip_router 129.123.1.254 ip_netmask 255.255.255.0 tcp_sockets 8 udp_sockets 8 raw_sockets 1 nb_sessions 4 nb_commands 8 nb_adapter 0 nb_domain usu.edu At the moment there is no Windows support for Kermit over ODI. Kermit's built-in TCP/IP support in v3.11, as well as several other of its networking methods, use BIOS Int 14H internally. This can interfere with other devices whose drivers use the same interrupt, for example speech devices connected to a serial port. Version 3.12 avoids this problem. Domain name resolution might not work when you give a nickname instead of a complete host name in the SET PORT TCP/IP command and Kermit transforms the nickname into the desired complete host name by combining it with your TCP/IP DOMAIN. Notice that Kermit does not use a special Hosts file to relate nicknames to complete host names. Workarounds: use a complete hostname, an IP host number, or set your TCP/IP DOMAIN correctly. It should be obvious that Domain Name Servers are specified by their IP number rather than name. Version 3.12 supports multiple gateways off the local network. Choosing the incorrect gateway normally results in that gateway sending an ICMP Redirect message to Kermit indicating the preferred gateway, and Kermit displays such messages. Version 3.11 did not implement ICMP Redirect actions. For IBM mainframe linemode connections, automatic appearance of the login banner might not work. Type a carriage return (Enter) to get the login banner. Local-echo and linemode operation are negotiated automatically. BOOTP requests are handled correctly within the local network, and have been tested successfully through Novell's BOOTP forwarder NLM and through Cisco routers with software version 8.2.7. In the SET TCP/IP ADDRESS command, the words BOOTP and RARP must be spelled out in full. EXIT from Kermit closes your TCP/IP session (just like HANGUP). PUSHing or running DOS commands from Kermit keeps it open. In version 3.12, EXITing while a session is active causes a confirmation message to appear, so you can change your mind. Kermit can connect to any TCP port other than SMTP (25, mail), but version 3.11 uses only TELNET port (23). Kermit honors TELNET protocol negotiations, including terminal type and ECHO/SGA. Version 3.11 sends "VT100"; version 3.12 sends the active terminal type or allows the user to create a string with command SET TCP/IP TELNET-TERM-TYPE. TELNET protocol echo negotiations do not work with certain hosts, protocol converters, or terminal servers. Some examples include Xyplex terminal servers, MICOM Interlan NTS100 terminal servers, MVS/TSO systems accessed via Fibronics KNET/MVS 3.0, Network Research Corp's TCP/IP for VAX/VMS. (This should be fixed in version 3.12). TELNET options are often implemented strangely on terminal servers, so beware. Not supported: FTP, TFTP, multiple sessions, automatic setting of PC date/time from network, 3270 emulation (tn3270), etc. There is no PING command, but MS-DOS Kermit responds when PINGed and when probed by Traceoute. The keyboard verb \Knethold does nothing. For TCP/IP connections to IBM mainframes in full screen 3270 mode, you need an intermediate host or device to do the 3270/ASCII terminal conversion. Typical setup is a TCP/IP terminal server with its serial lines connected to a protocol converter (e.g. IBM 7171), a UNIX host that has tn3270 available, or a terminal server (like Cisco) that does 3270 terminal emulation. To transfer files with an IBM mainframe, you might have to tell MS-DOS Kermit to SET PARITY SPACE. Version 3.12 supports inbound connections to MS-DOS Kermit but version 3.11 does not. Inbound TELNET connections do not copy DOS screens, etc, in the manner of products such as Carbon Copy and PC Anywhere and the free telnetd program of Erick Engelke; a Kermit-to-Kermit connection is made instead. MS-DOS Kermit does not provide any services except PING, i.e. ICMP ECHO, and Traceroute replies to outside requestors. You can't "finger" it, mail to it, etc. Kermit's TCP/IP support cannot be used simultaneously with PC NFS because both applications want to register use of ARP, IP, and other protocols with the packet driver, but each protocol can only be assigned to one application. This is only one particular case of the more general rule: only one TCP/IP based application can use a LAN adapter at once. To make Kermit TCP/IP connections under Windows 3.0 (Enhanced Mode), configure its .PIF file to "Lock Application in Memory", or preferably use the WINPKT shim. Only one copy of Kermit can have a TCP/IP connection at a time. The SET TCP/IP and SET PORT TCP/IP commands only return failure codes if there is a parse error. The connection is not opened until the first attempt to communicate with the remote host: CONNECT, PAUSE, OUTPUT, etc. While connection establishment is in progress, you can't interrupt the program with Ctrl-C. Use IF SUCCESS / FAILURE after PAUSE 0 to check if the connection is open, for example: DEFINE TELNET SET PORT TCP \%1 \%2, PAUSE 0, IF SUCCESS CONNECT The second variable above is for the optional TCP port number in version 3.12. Performance hints: Set your Kermit packet size to about 500, so it will fit inside network packets, or to some multiple thereof. A packet size of, say, 600 (or 1100, etc) gives poor performance, because the result on the net is a long and a short packet. A convenient setting is SET RECEIVE PACKET 2000, SET WINDOW 4, resulting in four 500-byte packets in a window. SET FLOW NONE lets TCP/IP do the flow control and eliminates Kermit's need to check for Xon/Xoff. In most situations beyond the local network performance will be limited by the long distance lines rather than by the PC. End of MSKERM.BWR / KERMIT.BWR